Wide area networks (WANs) are used to connect local area networks (LANs) together, so that users and computers in one location can communicate with users and computers in other locations. Owing to the ongoing development/proliferation of WANs, such as the Internet and similar Internet Protocol (“IP”) based networks (hereinafter more generally referred to as “IP networks”), more and more people use IP networks to exchange various types of information such as data, video and audio—including voice and fax calls (which are herein defined as any call(s) correction(s) which permit or actually transmit or receive signals corresponding to any one or more of the aforementioned types of information, all of which are more generally referred to herein as “fax calls”). Since communication of fax calls between two suitable (herein sometimes called “fax”) machines over IP networks typically involves transmission and reception of fax tones and fax data through gateways, such gateways are adapted to handle both fax over Internet Protocol (“FoIP”) and other information, such as voice over Internet Protocol (“VoIP”) communications. Therefore, gateways typically include a fax relay for enabling such fax calls, and speech coder and voice band data (“VDB”) paths for enabling verbal and modem communications.
In a communication network, the term “gateway” (also called protocol converter) generally refers to a network node that is equipped for interfacing with another network that uses different protocols. A gateway is commonly positioned at a common intersection between a Local Area Network (“LAN”) and a WAN, and it may contain devices such as protocol translators, impedance matching devices, rate converters, fault isolators, or signal translators as necessary to provide system interoperability. A protocol translation/mapping gateway interconnects networks with different network protocol technologies by performing the required protocol conversions. Routers are special cases of gateways. More about gateways may be found in “Access Gateways” (International Engineering Consortium, 2005).
Because of the different features and requirements that are involved in fax and voice communications, two different types of packet streams are typically independently used in two different modes of operations. The first type of packet stream is used in VoIP communications and is known as a real-time transfer protocol (“RTP”) packet stream. An International forum called the Audio Video Transport (“AVT”) Internet forum defined the RTP protocol in several Request For Comment (“RFC”) specifications, for different media types and purposes. For example, common RFCs for VoIP are RFC 3550 (“A Transport Protocol for Real-Time Applications”), which obsoletes RFC 1889, RPC 2198 (“RTP Payload for Redundant Audio Data”), RFC 2733 (“An RTP Payload Format for Generic Forward Error Correction”) and RFC 2833 (“RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals”).
Typical signals that are transferred over the RTP path are voice signals, dual-tone multi-frequency (“DTMF”) signals, channel-associated signaling (“CAS”), modem signals that are relayed according to RFC 2833 specification(s) or transferred in Voice-Band-Data (“VBD”) mode, video signals and the like. A RTP path, which may be used for processing RTP and RTP-related data, may include use of procedures that facilitate the encryption and/or protection of streams of packet loss, packets reordering and other procedures. Switching between different types of RTP streams (for example, regular voice, DTMF, VBD and video data) is performed in real-time by using payload types (as unique stream identifiers) transferred within (encapsulated in) RTP headers. Usually, switching between different types of RTP streams does not require any real-time negotiation between gateways involved in the communication session.
Attempting to utilize RTP path as is (without adaptation) to communicate fax data typically results in rendering the devices involved in the communication (the gateways and fax machines, for example) significantly less reliable and less interoperable. Therefore, a different type of a packet stream is involved in FoIP communications, which is known to a person with skill in the art as a “T.38 packet stream”. T.38 packet streams are processed in a T.38 path. The term “T.38 path” generally refers to an electronic circuit which may be located or associated with a gateway and an associated processing routine that are involved in the processing (encoding, decoding, recovery and so on) of a fax relay data stream (T.38 packet stream). A T.38 data packet is formatted according to T.38 Recommendations and relayed over IP networks by using TCP or UDPTL. A T.38/TCP protocol which introduces large delays of fax signals is seldom used and, therefore, this type of protocol will not be referred to hereinafter. The T.38/UDPTL transport includes procedures that facilitate the protection of streams of packet loss and packet reordering for enabling the communicating gateways to independently correct T.38 stream errors. These procedures include the use of UDPTL sequence numbers and error protection scheme(s). A typical error recovery method used in T.38 UDPTL includes using a redundancy feature that utilizes “secondary packets”. Another UDPTL error recovery scheme utilizes parity forward error correction (“FEC”). The latter mentioned two procedures or schemes are more fully described in the T.38 Recommendation.
Each type of packet stream has advantages and drawbacks, as more fully described hereinafter. For example, the T.38/UDPTL protocol is a well-known protocol that has long been in extensive use by fax relays, and it has an advantage that gateways and fax machines from different vendors introduce high interoperability, which means that different gateways/fax machines and the like can exchange fax messages in a convenient way, regardless of the vendor of the device (gateway, fax machine and the like) involved in the communication. In addition, T.38/UDPTL allows duplication of UDPTL packets for ensuring that at least one packet of its kind will be received intact at the receiving (remote) gateway or other device. For example, a gateway may generate five copies, or replicas, of a packet and successively forward them over the IP network to a receiving gateway, which will probably receive the original packet, or at least one of its replicas. However, as opposed to the RTP protocol, the T.38/UDPTL protocol does not allow encryption, which may render information susceptible to interception. In addition, UDPTL packets are not time stamped and, therefore, no communications-related statistics may be calculated, or evaluated, though this is usually not as critical in fax communications as it is in cases of real-time audio applications.
Regarding RTP packet streams, each RTP packet within a transmitted stream is assigned a unique sequence number and timestamp that may be utilized by the receiving gateway to calculate packets' statistics, evaluate the quality of the communication path and collate (reorder) packets that were received out of order. For example, statistics calculations may relate to the travel time of packets that arrive at the gateway, delay, jitter and so on. In addition, RTP allows encryption of data and, thus, it offers an improved security of communicated data. However, assigning (as by the gateway) a unique sequence number to each RTP packet also has a drawback, which is its inability to duplicate packets.
RTP and T.38 packet streams are generally handled by the gateways independently of one another. Regarding a given gateway at a given communication state, either an RTP packet stream or an T.38-type packet stream may be handled by the gateway, but not both types at the same time. Put differently, if a fax machine operates as a telephone (or as a fax machine), the gateways involved in the voice (or in the fax data) communication will enable the RTP path (or the T.38 path) while disabling the T-38 path (or the RTP path), respectively.
Therefore, whenever a fax call involves transmission of voice signal/fax tones and fax data, the gateways involved in the fax call have to switch from one mode of operation (such as RTP or T.38) to the other mode of operation (T.38 or RTP). That is, these gateways will, at times, enable the RTP path to handle a RTP packet stream (the VoIP part of the call), while disabling the T.38 path, and, at other times, they will enable the T.38/UDPTL path to handle a T.38 packet stream (the FoIP part of the call), while disabling the RTP path. The term “disabling the T.38 (or RTP) path”, refers to disabling an electronic circuit and/or (depending on the communication progress and application type) a software module/element that are normally involved in the processing of the T.38 (or RTP) data stream. In order for the gateways involved in the communication session to correctly switch between a RTP mode of operation and a T.38 mode of operation, the gateways may initiate a real-time negotiation by using a special protocol or auxiliary commands that may be forwarded to the gateways by a media gateway controller, for example, to inform, or notify, the gateways about the expected type of data stream that is about to arrive at the gateways. In cases where a gateway forwards both RTP and T.38 packets streams (not at the same time) via the same destination port, such a real-time negotiation is mandatory.
Transitions between RTP to T.38/UDPTL modes of operations are problematic because there is a need to timely enable/disable different circuitry and processes that are involved in each mode of operation, in addition to enabling/disabling circuitry and processes that are involved in real-time negotiations between two gateways, as is more explained hereinafter.
In order to eschew transitions between RTP (or T.38) and T.38 (or RTP) modes of operation, attempts have been made to combine T.38 functionality and RTP functionality. According to a newly suggested T.38-based protocol, a T.38 IFP primary packet (within a T.38 IFP packet stream) is to be encapsulated in RTP with a RTP header and optional RTP redundancy or FEC to form a T.38/RTP (IFP over RTP, or IFP/RTP for short) protocol, as opposed to the T.38/UDPTL (or IFP/UDPTL) protocol. The new protocol (T.38/RTP) has several advantages over the T.38/UDPTL, as described hereinafter. For example, the T.38/RTP protocol enables secured fax relay transport by using secure RTP (“SRTP”) which is a communication standard commonly used by different types of RTP media.
In addition, the newly suggested T.38/RTP protocol enables relatively fast transitions between voice (audio over RTP) and fax (IFP packets over RTP) packet streams by automatically distinguishing between the different types of RTP payloads without spending time for real-time negotiation between the two communicating gateways, as opposed to T.38 UDPTL protocol.
In addition, RTP encapsulation allows utilizing RTP Control Protocol (“RTCP”) for statistics evaluations. RTCP is defined in RFC 3550. RTCP stands for Real-time Transport Control Protocol, and it provides out-of-band control information for a RTP packet stream. The primary function of RTCP is to provide feedback on the quality of service being provided by RTP, by periodically transmitting control packets to participants in a streaming multimedia session. It gathers statistics on a media connection and information such as bytes sent, packets sent, lost packets, jitter, feedback and round trip delay. An application may use this information to increase the quality of service, for example by limiting data flow, or by using a low compression codec instead of a high compression codec.
According to the new T.38/RTP protocol, primary IFP packets eschew T.38 UDPTL formatting and pass via RTP path instead, as if they were a real-time media data/signal. To implement the new T.38/RTP protocol, the RFC 3550 is used instead of T.38 UDPTL. For enhancing the protection of facsimile communication and recovery of lost packets, and for enabling collation of (reordering) packets, the T.38 standard recommends using an optional redundancy means as specified by RFC 2198, or, alternatively, by using FEC stream as specified by RFC 2733, the content of which is herein incorporated by reference.
The new T.38/RTP protocol also has several drawbacks. For example, using IFP/RTP often results in significant increase in the consumption of computational resources, comparing to T.38/UDPTL. In part, the need to use more computational resources results from the attempt to overcome discrepancies between different RTP and T.38/UDPTL requirements, which exist because the RTP protocol was not originally designed to cope with fax data communications. In addition, the interoperability offered by the IFP/RTP protocol may be poorer in comparison with the IFP/UDPTL protocol because of application of timestamps to fax data. Other drawbacks of the suggested IFP-over-RTP (IFP/RTP) protocol will be apparent from the description of the figures.